User-Centred Requirements Handbook |
This method is concerned with developing different proposed concepts through software or hardware prototypes, and evaluating them. In general the process is termed 'rapid' prototyping. The development of a simulation or prototype of the future system can be very helpful, allowing users to visualise the system and provide feedback on it. Thus it can be used to clarify user requirements options. Later on in the lifecycle, it can also be used to specify details of the user interface to be included in the future system.
A major difficult in system design is getting the concept itself across to the users. Whereas a rapid prototype can demonstrate the system concept well, paper prototyping methods may be less effective.
Rapid prototyping is described as a computer-based method which aims to reduce the iterative development cycle. Interactive prototypes are developed which can be quickly replaced or changed in line with design feedback. This feedback may be derived from colleagues or from the experiences of users as they work with the prototype to accomplish set tasks.
Within software engineering circles the method is closely associated with user interface management systems and various design support tools. The latter tools offer the designer libraries of process and graphical interface elements for defining the software's logical structure and 'look-and-feel'. Here the title refers to an approach adopted by software developers in which the prototypes exhibit a higher fidelity with the end product than those created as part of other methods such as paper prototyping.
Many tools exist for producing rapid prototypes ranging from a sequence of Microsoft PowerPoint screens, to script based programming systems such as HyperCard, Toolbook and Visual Basic which can help to create a software prototype. Thus the method requires more sophisticated technical resources than is the case with low-fidelity prototyping methods which rely on paper materials. An additional cost of use is the level of human expertise required to master the supporting development tools, along with the time necessary to implement a software prototype. A member of staff is also required to direct users if the prototype is to be evaluated formally.
What you need
Requires programming or model building skills to produce the prototypes. A number of prototype iterations may be carried out or a parallel design approach where two or more designers produce design ideas that are prototypes. The process of obtaining user feedback will also incur a certain amount of cost in terms of time and effort.
Benefits
• Gives users (especially the general public) a tangible demonstration of what the system is about.
• Permits the swift development of interactive software prototypes.
• Prototypes created by this method have a high fidelity with the final product.
• The prototypes created under this method support metric-based evaluations.
Limitations
• The method requires software development skills.
• Although rapid, the method is more time consuming than other approaches.
• The resources required are greater due to the need for software and hardware rather than paper and pens.
Process
A general procedure for adopting the rapid prototyping method is outlined below.
1. Firstly, allow enough time to create the prototype. If the prototype is to be evaluated with users then allow time to design relevant tasks, recruit the users, evaluate the prototype and report the results.
2. Assemble the necessary equipment, including the hardware and software tools necessary to create the interactive prototype.
3. Develop the prototype itself.
4. Select appropriate users to test the prototype, trying to cover the range of users within the target population. A facilitator will also be required to instruct the users and run the evaluation.
5. Prepare realistic tasks to occupy the users as they work with the prototype.
6. Pilot the evaluation procedure and ensure the prototype can be used to accomplish the tasks.
7. Ensure recording facilities are available and functioning.
8. Conduct each session. The facilitator instructs the user to work through the allocated tasks, interacting with, and responding to, the system as appropriate.
9. If necessary additional information can be obtained by interviewing users following their use of the prototype.
10. Debrief and thank the user.
11. Analyse the obtained information and then summarise the observations and user evaluations. Determine the themes and severity of the problems identified.
12. Summarise design implications and recommendations for improvements and feed back to design team. Video recordings can support this.
13. Where necessary refine the prototype and repeat the above process.
Practical guidelines
• Avoid spending too long on the development of the first prototype as uses may require substantial changes to it. Similarly try not to put too much effort into particular features (e.g. animations) which may not be required.
• Avoid making the prototype too polished as this may force users to accept it as finished.
• Avoid putting in features that will raise the users expectations but which are unlikely to be achieved with the real system (e.g. too fast response times, too sophisticated graphics).
Further information
Maguire (1996), Preece (1994), Wilson, J. and Rosenberg, D. (1988).